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Class Overview 



Primary Goals: 

a Learn how to use pFUnit 3.0 to create and run unit-tests 
a Learn how to apply test-driven development methodology 
Prerequisites: 

a Access to Fortran compiler supported by pFUnit 3.0 
a Familiarity with F95 syntax 
a Familiarity with MPI 1 
Beneficial skills: 

a Exposure to F2003 syntax - esp. 00 features 
a Exposure to 00 programming in general 


^Pl-specific sections can be skipped without impact to other topics. 


April 10, 2014 


4/90 


Tom Clune (ASTG) 


Syllabus 



a Thursday PM - Introduction to pFUnit 

► Overview of pFUnit and unit testing 

► Build and install pFUnit 

► Simple use cases and exercises 

► Detailed look at framework API 

9 Friday AM - Advanced topics (including TDD) 

► User-defined test subclasses 

► Parameterized tests 

► Introduction to TDD 

► Advanced exercises using TDD 

9 Friday PM - Bring-your-own-code 

► Incorporate pFUnit within the build process of your projects 

► Apply pFUnit/TDD in your own code 

► Supplementray exercises will be available 
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Materials 

Q You will need access to one of the following Fortran compilers to do 
the hands-on portions 

► gfortran 4.9.0 (possibly available from cloud) 

► Intel 13.1, 14.0.2 (available on jellystone) 

► NAG 5.3.2 

O Last resort - use AWS 

► ssh keys are at ftp://tartaja.com 

► username: pfunitOtartaja. com passwd: iuse. PYTHON. 1969 

► login: ssh -i userl userl@54.209.194.237 

Q You will need a copy of the exercises in your work environment 

► Browser: https : //modelingguru.nasa.gov/docs/DOC-2529 

► Jellystone: 

/picnic/u/home/ cacruz/pFUnit . tutorial/Exercises .tar 

O These slides can be downloaded at 

https : //modelingguru . nasa . gov/ docs/DOC-2528 
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Peeking under the hood - what is inside pFUnit? 
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Hierarchy of Test Classes 
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Role: Abstract base class for all test objects. 

Implementation: Framework provides various subclasses for 
common/generic cases. Users can define custom subclasses for specific 
purposes. Provided subclasses include: 

9 Test Case 
9 TestMethod 
9 MpiTestCase 
9 MpiTestMethod 
9 TestSuite 
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TestSuite 



Role: Aggregates collection of tests into single entity. 

Implementation: TestSuite objects are simultaneously Test objects and 
collections of tests. Run() method applies run() to each contained test. 
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TestCase class 



Role: Abstract Test subclass that provides some services that are common 
to most Test subclasses. 

Implementation: 
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TestMethod class 



Role: Simple concrete Test subclass that supports the common case 
where test procedure receives no arguments. 

Implementation: Constructor stores a procedure pointer to vanilla 
Fortran subroutine with no arguments. A restricted form of test fixture is 
permitted by specifying setUp() and tearDown() methods that also have 
no arguments. (I.e. fixture is not encapsulated.) 
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TestMethod API 



Constructor: 


function TestMethod (name , method [ , 
char act er ( len = * ) , intent (in) :: 


procedure (empty) 
procedure (empty) 
procedure (empty) 


method 

setUp 

tearDown 


setUp, tearDown]) 
name 


Methods: 
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ParameterizedTestCase class 



Role: Allows a single test procedure to be execute multiple times with 
different input values. 

Implementation: ParameterizedTestCase objects contain an 
Abstract TestParameter object that encapsulates input. Subclasses of 
ParameterizedTestCase must generally also subclass 
A bstract Test Para meter. 


pFUnit 3.0 - API - Advanced - Session II 


April 10, 2014 17 / 90 


Tom Clune (ASTG) 



MpiTestCase class 



Role: (Abstract) Extends ParameterizedTestCase with support for MPI. 
Implementation: MpiTestCase modifies the runBare() launch mechanism 
to create an appropriately sized MPI group and corresponding 
subcommunicator. Processes within that group then call the user's test 
procedure, while any remaining processes wait at a barrier. 

MPI based tests must not use MPI_C0MM_W0RLD, and must instead obtain 
MPI context from the passed test object. 

The following convenient type-bound procedures are provided: 

getProcessRank () / returns rank within group 

getNumProcesses () / returns size of group 
getMpiCommunicator () / returns the bare MPI com 


pFUnit 3.0 - API - Advanced - Session II 


April 10, 2014 19 / 90 


Tom Clune (ASTG) 



M pi Test Met hod class 



Role: Simple concrete Test subclass that supports common MPI cases 
that just need basic MPI context. 

Implementation: Analogous to the vanilla TestMethod, except that user 
test procedures are now passed an object which must be queried for any 
MPI context that the test needs. 
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M pi Test Met hod API 



Constructor: 

function MpiTestMethod (name , method, numProcesses , [, setUj 

character ( len=*) , intent (in) :: name 

procedure ( empty ) :: method 

integer :: numProcesses / requested 

procedure ( empty ) :: setUp 

procedure ( empty ) :: tearDown 
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Q Introduction 


o API - Advanced 

9 API: pFUnit test Hierarchy 
9 API: Misc 

9 Parser: Advanced 

o Test-driven development 
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TestResult class 



Role: “Scorecard" - accumulates information about tests as they run. 
Implementation: Each run() method for Test objects has a mandatory 
TestResult argument. The Visitor pattern is used to allow the TestResult 
object to manage and monitor the test as it progresses. 

Note: Visitor is a somewhat advanced pattern and uses 00 capabilities in 
a nontrivial manner. Users should not need to be aware of this, but 
developers of framework extensions likely will. 
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Abstract BaseTestRunner class 



Role: Runs a test (usually a TestSuite). 

Implementation: Run() method constructs and configures a TestResult 
object, then runs the passed Test object. 
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TestRunner class 



Role: Default Runner for pFUnit. 
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RobustRunner class 



Role: Runner subclass that executes tests within a separate process. 
Implementation: Collaborates with SubsetRunner. RobustRunner restarts 
SubsetRunner if it detects a hang or a crash. Currently a bit unreliable. 
(Irony) 
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Q Introduction 


o API - Advanced 

a API: pFUnit test Hierarchy 
a API: Misc 

a Parser: Advanced 

0 Test-driven development 
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Annotations: QtestCase 

StestCase 

@testCase (<options >) 



9 Indicates next line defines a new derived type which extends TestCase. 

9 All test procedures in file must accept a single argument of that 
extended type. 

® Accepts the following options: 

► constructor=<name> Specifies the name of the function to construct 
corresponding test object. Default is a constructor with same name as 
derived type 2 

► npes= [<list-of-integers>] Indicates that extension is a subclass 
of MpiTestCase, and provides a default set of values for NPES for all 
test procedures in the file. Individual tests can override. 

► esParameters={expr} Indicates that extension is a subclass of 
ParameterizedTestCase, and provides a default set of parameters for all 
tests in the file. Can be overridden by each test. 

► cases= [<list-of-integers>] Alternative mechanism for specifying 
default test parameters where a single integer is passed to the test 

constructor. 
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Annotations: @test Parameter 
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Encapsulated test fixture 

module SomeTests_mod 
use pFUnit_mod 
implicit none 
©testCase 

type, extends ( TestCase ) MyTestCase 
real, allocatable x I n i t i a I ( : ) 
contains 

procedure setUp 

procedure tearDown 

end type MyTestCase 
contains 

subroutine setup(this) 

class (MyTestCase), i n t e n t ( i n o u t ) this 

xlnitial = [1. ,3. ,5. ,3. ,1.] 
end subroutine setup 

subroutine tearDown ( t h i s ) 

class (MyTestCase), i n t e n t ( i n o u t ) this 

deallocate ( thi s%x Initial ) 
end subroutine tearDown 
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Encapsulated test fixture (cont’d) 



1 ©test 

subroutine a n ot h e rTest ( t h i s ) 

• class ( MyTestCase ) , i n t e n t ( i n o u t ) this 

real , allocatable x ( : ) 

> x = oneStep ( t h i s%x I n i t i a I ) 

I ©assert Equal (...) 

! end subroutine anotherTest 

end module MyTests.mod 
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Encapsulated test fixture (cont’d) 



What you need to know: 

a Declare derived type that EXTEND' s TestCase 
» Annotate TestCase extention with OtestCase 
9 Declare TYPE-BOUND procedures: setUp and tearDown 
9 Annotate test procedure in usual way with ©test 
9 Declare single test procedure argument as 

class (<your type>), i n t e n t ( i n o u t ) :: <dummy> 
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MPI test fixture 

module SomeM piTests.mod 
! use pFUnit.mod 

1 implicit none 

> OtestCase ( n pes = [ 1 , 3 , 5] ) 

i type, extends ( MpiTestCase ) MyTestCase 

i nteger : rank , npes 

! integer :: peEast , peWest 

> contains 

l procedure setUp 

procedure tearDown 
! end type MyTestCase 

contains 



subroutine setup(this) 

class (MyTestCase), i n t e n t ( i n o u t ) this 

integer rank, npes 
this%rank = t h i s%get P rocess Ra n k ( ) 
this%npes = t h i s%get N u m P rocesses ( ) 

this%peWest = mod ( t h i s%ra n k + this%npes — 1, this%npes) 
this%peEast = mod ( t h i s%ra n k + 1, this%npes) 
end subroutine setup 
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MPI test fixture (cont’d) 



» ©test 

i subroutine a n ot h e rTest ( t h i s ) 

class ( MyTestCase ) , i n t e n t ( i n o u t ) this 

> integer comm 

I real : : x (0:2) 

! comm = t h i s%getM piCom m u n icator ( ) 

call some M pi P roced u re (comm , x ) 

i @mpi Assert Equa I ( t h i s%peWest , x(0)) 

©mpi Assert Equal ( t h i s%ra n k , x(l)) 

! OmpiAssertEqual ( t h i s%peEast , x(2)) 

i 

I end subroutine anotherTest 

! end module MyTests.mod 


April 10, 2014 42 / 90 


Tom Clune (ASTG) 



MPI test fixture (cont’d) 



What you need to know: 

® Declare derived type that EXTEND’ s MpiTestCase 
« Annotate TestCase extention with OtestCase 

► Optionally specify default npes list: (npes= [...]) 
a Declare TYPE-BOUND procedures: setUp and tearDown 
® Annotate test procedure in usual way with ©test 
® Declare single test procedure argument as 

class (<your type>), i n t e n t ( i n o u t ) :: <dummy> 

® Use OmpiAssert* to synchronize returns 
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Parameterized tests 



Suppose you want to test an interface using variant input data: 
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Parameterized tests 



Suppose you want to test an interface using variant input data: 
E.g. sorting a list ... 


list = sort ( [ 1 , 2 , 3 , 4] ) 
list = sort ( [4 , 3 , 2 , 1] ) 
list = sort ( [ 1 , 4 , 2 , 3] ) 
list = sort ( [ 1 , 2 , 3 , 1] ) 


April 10, 2014 46 / 90 


Tom Clune (ASTG) 



Parameterized tests 



Suppose you want to test an interface using variant input data: 
E.g. sorting a list ... 

list = sort ( [ 1 , 2 , 3 , 4] ) 
list = sort ( [4 , 3 , 2 , 1] ) 
list = sort ( [ 1 , 4 , 2 , 3] ) 
list = sort ( [ 1 , 2 , 3 , 1] ) 

or varying boundary conditions... 

call solve (x , BC= ’ dir ichlet J ) 
call solve (x, BC= J neumann ’ ) 
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Parameterized tests (cont’d) 



One simple strategy is to just duplicate tests: 

©test 

subroutine testl () 

©assertEqual ( [1 ,2 ,3,4] , sort ( [1 ,2 ,3 ,4] )) 
end subroutine testl 

©test 

subroutine test2() 

©assertEqual ( [1 , 2 , 3 , 4] , sort ( [4 , 3 , 2 , 1] ) ) 
end subroutine test2 
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Parameterized tests (cont'd) 



One simple strategy is to just duplicate tests: 

©test 

subroutine testl () 

©assertEqual ( [1 ,2 ,3,4] , sort ( [1 ,2 ,3 ,4] )) 
end subroutine testl 


©test 

subroutine test2() 

©assertEqual ( [1 , 2 , 3 , 4] , sort ( [4 , 3 , 2 , 1] ) ) 
end subroutine test2 


This can be quite tedious if there are many cases and/or the tests are 
more complex. 


April 10, 2014 48 / 90 


Tom Clune (ASTG) 



Parameterized tests (cont'd) 

Another approach is to loop within a test 

©test 

subroutine test() 

real , allocatable x ( : ) 

call checkDeriv (x , x**0) 
call checkDeriv (x**2 , 2*x) 
call checkDeriv (x**3 , 3*x**2) 



contains 

subroutine checkDeriv(fx, dfx) 
real ,intent(in) fx 

real , intent(in) dfx 

@assertEqual(dfx, deriv(fx)) 
end subroutine checkDeriv 

end subroutine testl 
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Parameterized tests (cont'd) 

Another approach is to loop within a test 

©test 

subroutine test() 

real , allocatable x ( : ) 

call checkDeriv (x , x**0) 
call checkDeriv (x**2 , 2*x) 
call checkDeriv (x**3 , 3*x**2) 



contains 

subroutine checkDeriv(fx, dfx) 
real ,intent(in) fx 

real , intent(in) dfx 

@assertEqual(dfx, deriv(fx)) 
end subroutine checkDeriv 

end subroutine testl 


Here we lose information about which case(s) failed. 
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Parameterized tests (cont'd) 



pFUnit provides custom support for parameterized tests: 
a Exercise tests across list of user-defined parameters 
« User EXTEND’s two classes: 

► ParameterizedTestCase (analog of TestCase) 

► AbstractTestParameter 

» Annotation argument: testParameters={<expr>> 

► Specifies default parmeter list for StestCase 

► Override with argument to Otest 

9 Failures indicate parameter caused failing assert. 

► Provided through type-bound interface toStringO on 
AbstractTestParameter 
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Example: Parameterized test 



7 ©testParameter 

8 type, extends ( AbstractTestParameter ) St ri ngTest Pa ra m ete r 


9 

character ( 

), allocatable 

string 

10 

character ( 

), allocatable 

lowerCase 

11 

character ( 

), allocatable 

upperCase 

12 

contains 



13 

procedure 

toString 


14 

end type Strin 

gTest Parameter 



66 function toString(this) result ( 

67 class (StringTestParameter), 

68 character (: ) , allocatable 

69 

70 string ='{’// this%string 

// t h i s%u p pe rCa se // 

71 

72 end function toString 


string) 

intent(in) this 
string 

// >' // t h i s%lowerCase // 
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Example: Parameterized test (cont’d) 


16 ©testCase ( testParameters = { get Pa ra ms ( ) } , co nst r uct or= 

newTest_StringUtilities) 

17 type, extends(ParameterizedTestCase) Test_StringUtilities 

18 character (: ) , allocatable :: string 

19 character (: ) , allocatable :: lowerCase 

20 character (: ) , allocatable uppercase 

21 end type T e s t _ S t r i n g U t i I i t i e s 

24 

25 function getParams() r e s u 1 1 ( pa ra ms ) 

26 type ( S t r i n gTest P a r a m et e r ) , allocatable params ( : ) 

27 

28 params = [ & 

29 StringTestParameter('a’,'a’,'A’) 

30 StringTestParameterpb'.’b'.'B') 

31 StringTestParameter(’A' .'a’.'A') 

32 StringTestParameter(’l , ,'l’,’l’) 

33 StringTestParameter('+', 

34 StringTestParameter( ’ alB2c3D4 ' , 

& 


& 

& 

& 

&t 

alb2c3d4 ' , ’A1B2C3D4') 



end function getParams 
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Example: Parameterized test (cont’d) 



48 ©test 

49 subroutine t es t _t o Lo we r C a se ( t h i s ) 

50 class (Test.StringUtilities), intent(inout) this 

51 

52 ©assert E q u a I ( t h i s%l o we rCa se , to Lower Case ( t h i s%s t r i n g ) ) 

53 

54 end subroutine test.toLowerCase 

55 

56 

57 ©test 

58 subroutine t es t _t o U p pe r C a se ( t h i s 

59 class (Test.StringUtilities), 

60 

61 ©assert Eq ua I ( t h i s%u pperCase , 

62 

63 end subroutine test.toUpperCase 


) 

intent(inout) this 
toUpperCase( this%string )) 
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Example: Parameterized test (cont’d) 



To specify a variant list of parameters: 

@test(testParameters={getOtherParams()}) 
subroutine test_toUpperCase( this ) 

class ( T e s t _ S t r i n g U t i I i t i e s ) , i n t e n t ( i n o u t ) :: this 

OassertEqual ( thi s%up per Case , toUpperCase(thi s%st ring ) ) 

end subroutine test_toU pperCase 
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Combining MPI and Parameterized Test 
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Good news: 

MpiTestCase is a subclass of ParameterizedTest 
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Combining MPI and Parameterized Test 



Good news: 

MpiTestCase is a subclass of ParameterizedTest 
a Extend MpiTestCase 

9 Extend MpiTestParameter (invisible with simple MPI) 
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Combining MPI and Parameterized Test 



Good news: 

MpiTestCase is a subclass of ParameterizedTest 
a Extend MpiTestCase 

9 Extend MpiTestParameter (invisible with simple MPI) 

9 Framework augments toStringO to ensure that rank/npes is always 
included in failure messages 
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0 Introduction 
0 API - Advanced 

Q Test-driven development 
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TDD 
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Old paradigm: 

« Tests written by separate team (black box testing) 
9 Tests written after implementation 
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Old paradigm: 

« Tests written by separate team (black box testing) 
9 Tests written after implementation 

Consequences: 

9 Testing schedule compressed for release 
9 Defects detected late in development ($$) 
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Old paradigm: 

9 Tests written by separate team (black box testing) 
9 Tests written after implementation 

Consequences: 

9 Testing schedule compressed for release 
9 Defects detected late in development ($$) 


New paradigm - Test-driven development (TDD) 

9 Developers write the tests (white box testing) 

9 Tests written before production code 
9 Enabled by emergence of strong unit testing frameworks 
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The TDD cycle 



focus on interface focus on algorithm 



FUnit 3.0 - Test-driven development - Sessic 


April 10, 2014 66 / 90 


Tom Clune (ASTG) 


Anecdotal Testimony 



a Many professional SEs are initially skeptical 

► High percentage refuse to go back to the old way after only a few days 
of exposure. 

a Some projects drop bug tracking as unnecessary 
a Often difficult to sell to management 

► "What? More lines of code?" 


pFUnit 3.0 - Test-driven development - Sessic 
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Not a panacea 
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► No such thing as magic 
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a Requires training, practice, and discipline 
a Need strong tools (framework + refactoring) 
a Does not invent new algorithms (e.g. FFT) 

► No such thing as magic 

a Maintaining tests difficult during a major re-engineering effort. 
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Not a panacea 



a Requires training, practice, and discipline 
a Need strong tools (framework + refactoring) 
a Does not invent new algorithms (e.g. FFT) 

► No such thing as magic 

a Maintaining tests difficult during a major re-engineering effort. 

► But isnt the alternative is even worse?!! 
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Experience to date 

TDD has been used heavily within several projects at NASA 

® Mostly for “infrastructure” portions - relatively little numerical 
® pFUnit itself 

® Snowfake - virtual snowfakes; Multi-lattice Snowfake 
® DYNAMO - spectral MHD code on shperical shell 
® GTRAJ - offline trajectory integration (C++) 

« SpF - 00 parallel spectral framework 



Observations: 

« ~ 1:1 ratio of test code to source code 
a Works very well for infrastructure 
« Learning curve 

► 1-2 days for technique 

► Weeks-months to wean old habits 
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TDD - Talking Points 

9 How large of a step at each cycle? 
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TDD - Talking Points 

9 How large of a step at each cycle? 



► Gauge by time 

► If steps are going quickly try larger changes 

► If iteration > 10 min, start iteration over (repository is your friend) 
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TDD - Talking Points 



o How large of a step at each cycle? 

► Gauge by time 

► If steps are going quickly try larger changes 

► If iteration > 10 min, start iteration over (repository is your friend) 
9 Triangulation 

► Start with simple tests 

► Add tests that probe weaknesses in existing implementation 

► Stop when it is apparent than new tests will all pass 


9 Don’t test constructors and accessors 
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TDD - Talking Points 



o How large of a step at each cycle? 

► Gauge by time 

► If steps are going quickly try larger changes 

► If iteration > 10 min, start iteration over (repository is your friend) 
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► Start with simple tests 

► Add tests that probe weaknesses in existing implementation 

► Stop when it is apparent than new tests will all pass 
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9 Commit/backup frequently 
9 Use synthetic data to make results obvious 
9 Private vs testable 
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► Add tests that probe weaknesses in existing implementation 
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9 Don’t test constructors and accessors 


9 Commit/backup frequently 
9 Use synthetic data to make results obvious 
9 Private vs testable 

► One module has everything PUBLIC 

► 2nd module is default private - just export the things you want PUBLIC 

► Tests use first module; application uses 2nd. 
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TDD - Talking Points 



o How large of a step at each cycle? 

► Gauge by time 

► If steps are going quickly try larger changes 

► If iteration > 10 min, start iteration over (repository is your friend) 
9 Triangulation 

► Start with simple tests 

► Add tests that probe weaknesses in existing implementation 

► Stop when it is apparent than new tests will all pass 


9 Don’t test constructors and accessors 


9 Commit/backup frequently 
9 Use synthetic data to make results obvious 
9 Private vs testable 

► One module has everything PUBLIC 

► 2nd module is default private - just export the things you want PUBLIC 

► Tests use first module; application uses 2nd. 

9 Think when writing tests; autopilot when writing implementation 
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TDD - process reminder 



Q Extend test (new test procedure, new assert, etc) 
Q Verify test fails Red Light 
Q Alter implementation to pass test 
Q Refactor to eliminate redundancy Green Light 
Q Repeat 
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TDD Demonstration: Factorial 



Instructions: 

Use TDD to implement factorial function 

To make it interesting, we’ll add tests to guard against illegal inputs and 
overflow. 
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« Change into the directory . /Exercises/TDD.Warmup 
» Set PFUNIT for a serial build 

® °/ 0 make tests (ensure that make is working for you) 
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TDD Demonstration: Dynamical System 



Instructions: 

We are going to build a set of classes that will integrate a simple 
dynamical system: 

9 State of system is specified by a scalar, t, and 2 vectors: x and v 
9 Denote timestep with h 
9 Force (F) on system is any function of x, v, t 
9 Initial integration will be via forward Euler: Y n+ 1 = Y n + hF(Y ni t ) 
9 Then we will “upgrade" to RK4 


essic 
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Possible unit tests for Dynamical System 



Forward Euler integration 

9 F(t) = 0, v(t = 0) = 0 leaves x n+ i = xo 
9 F(t) = 0, v(t = 0) = vo has x n+ i = nhvo 

9 F(t) = 0, v(t = 0) = v 0 has v n+1 = v n 

9 F(t) = F(t = 0) = a, v(t = 0) = x(t = 0) = 0 has v n+ \ = v„ + ha 
9 v n+ i = v n + hF(t n ) 

9 — x n -F hv n 

9 If h = 0, x n = xo and v n = vq for any F 
9 Vary number of dimensions 
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« Change into the directory . /Exercises/TDD_DnamicalSystem 
» Set PFUNIT for a serial build 

® °/ 0 make tests (ensure that make is working for you) 
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Runge-Kutta (RK4) 



Yn+ 1 — Yn + g h(ki + 2/C2 + 2/C3 + /C4) 

tfi ■ 1 — t n h 


k\ = f(t n ,y n ) 

1 h 

h = f{tn+ 2 h ’Yn+ 2 kl ) 

1 h 

kz = f{t n + -h,y n + -k 2 ) 
kz = f{t n + h,y n + hk 3 ) 
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Demo: Build a Linear ID Interpolator 
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Interpolation ... 



What are some potential tests? 
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Interpolation ... 



What are some potential tests? 

o Bracket: Find / such that x; <= x < x,-+i 
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Interpolation ... 



What are some potential tests? 

o Bracket: Find / such that x; <= x < x,-+i 
9 Computing weights: 


w a = 

X/+1 - X 

Xi+1 - Xi 

w b = 

1 — w a 
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Interpolation ... 


What are some potential tests? 
o Bracket: Find / such that x; 
9 Computing weights: 


w a 

w b 


9 Combining weighted sum: y 


= x < X/ + l 

Xj+l - X 
Xi + 1 - X/ 

= 1 — w a 
W a y, + w b y i+ 1 
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Tests for finding enclosing bracket 



{xi,x 2 ,x 3 } 

X 

Expect 

Comment 

3.} 

1.5 

/ = 1 

vanilla 

{1-2-3.} 

2.5 

/' = 2 

vary x 

{1—2—4.} 

3.0 

/' = 2 

irregular spacing 

{1 . ,2. ,4. ,5.} 

2.5 

/ = 2 

vary # of nodes 

{1-2-3.} 

2.0 

/ = 2 

edge case 

{1-2-3.} 

1.0 

/ = 1? 

edge case 

{1-2-3.} 

3.0 

/ = 2? 

edge case 

{1-2-3.} 

0.5 

exception? 

out-of-bounds 

{3-2. ,1-} 

1.5 

exception? 

support inverted order? 
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Tests for compute weights 



Xi 

*;+ 1 

X 

expected 

Comment 

1 . 

2. 

1.0 

o 

i-H 

II 

£ 

left end 

1 . 

2. 

2.0 

o 

o 

II 

£ 

right end 

1 . 

2. 

1.5 

LO 

O 

II 

£ 

middle 

1 . 

3. 

1.5 

w a = 0.75 

vary interval 

1 . 

2. 

0.0 

w a — ? 

out-of-bounds 

1 . 

1 . 

1.0 

? 

duplicate node 
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Tests for combine weights 



w a 

y a 

yb 

expected 

Comment 

1 . 

1 . 

2. 

y = 1.0 

left end 

0 . 

1 . 

2. 

y = 2.0 

right end 

0.5 

1 . 

2. 

y = 1.5 

middle 

0.5 

3. 

2. 

y = 2.5 

vary data 
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Live Demo: Cross Fingers 
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